How They Really Work

Osher Lifelong Learning Institute
University of Illinois, Urbana-Champaign

Scott Badman, Instructor

Programming

Nickel Counter machine language, and Assembly Language program (review)

NICKEL.ASM - Typical Assembly Language version.

Early high level languages

Nickel1.bas - example of Early BASIC program, which is similar to FORTRAN, without input or output

Can see direct relationship of BASIC code to machine code from CPU example

All addresses are now hidden, being replaced by variable names or line labels

The movement of data into and out of the Accumulator is hidden

Arithmetic operations look more like normal human arithmetic

The test for the jump is now written as an IF, much easier to understand as a human

The jump itself is now called a GOTO.

Nickel1a.bas - same program written the way it would have been written in the mid 1960's

Nickel2.bas - same program with input and output

Structured Programming

Nickel3.bas - much easier to understand as a human being

All jumps are now hidden -- no GOTO's

The loop is now called a WHILE loop -- more intuitive for humans

Notice the WEND, instead of END WHILE - a little quirkiness of BASIC going back to the designers

Example that you are interacting with a human engineer or designer, not the instrinsic logic of a computer

Overall effect is that a human can understand the logic of the program just by reading it.

The program itself says what it does

Programs are now more human oriented that machine oriented.

Can now easily see the four operations that comprise almost all programming

Assignment Statements - calculations using the ALU

If statements - jumping without repeat

Loops - jumping with repeats

Input / Output - similar in concept to the Assembly Language LOAD and STOR, but becomes complicated and makes use of the operating system, which is just another program

Complexity Problem

As computers became cheaper and more powerful, the growing size and complexity of major programs became a major problem.

Subroutines

Early solution (1950's to 1970's)

Put any parts of the code that repeat into a seperate section that is used over and over

JMP to a section of the program and then JMP back to where you were

Deliv123.bas - example of how complicated subroutines can get.

Solution (1970's to present)

Increased abstraction into self-contained program fragments, which are then used by other parts of the overall program

Give those self-contained program fragments names that say what they do.

Isolate the variable names into that program fragments only, so there is no confusion with the other parts of the program..

Procedural Programming

Switch to NickelCounter.java - same program as NICKEL3.BAS

Most programming languates are essentially the same -- More like the difference between American and Australian than French and German.

Using the same algorithm repeatedly in a larger program

Example: ChangeCounter.java (without procedures)

Divide the entire program into self-contained program fragments, called "procedures" or sometimes "functions"

Each procedure should do a single, well-defined task.

Give that procedure a name, usually a verb (because it does something)

Allow a prodecure in the program to activate other procedures to perform some sub-task for them.

All the variable names inside a prodcedure must be active inside that procedure only, even if a procedure has a variable of the same name.

ChangeCounter.java (with the remove procedure)

Object Oriented Programming

ChangeCounter.java (Object Oriented vesion)

Now both variables and procedures are put into a new type of self-contained program fragment called an "object".

The procedures inside an object work with the variables inside the object, as well as with any values passed to it.

The result is a kind of super-variable that now only olds values, but can do things with those values.

Object Oriented Programming creates really tough, efficient, interchangeable, highly self-contained program fragments.

It works, and is the best programming paradigm found so far.

Payoffs:

ChangeCounter.java (Graphic User Interface version)

Object Oriented Code easily used by other programmers -- it doesn't even have to be actually visible in the program.

Highly complex programs are easily understandable by other programmers.

Once a well designed "Object", really just a piece of code, is fully tested and proven, then there is little chance it will fail when used in other programs.

Changing something in ChangeCounter.java using Java Docs.